Many application programs provide a mechanism for end users to customize various aspects of the application. These customizations can modify the look and feel of the user interface, add or remove properties from various entities (e.g., invoice or contact), modify the values of a multiple choice field (i.e., a pick list), and so on. For example, if the application program is a customer relationship management (“CRM”) program that allows a user to track contact information, the user may customize the user interface by changing the color of a telephone number field or rearranging the address and telephone number fields of a form so that the telephone number is prominently displayed. As another example, a user who is a shoe salesperson may customize the contact information of the CRM program by adding a custom shoe size property for tracking the shoe sizes of the salesperson's customers. If the CRM program provides a default pick list of customer statuses (e.g., active and inactive), the salesperson may want to add a new status (e.g., prospect) to the pick list.
Such application programs typically store information describing the customizations in a customization store. When a new property is added to an entity, the application program may add an entry to the customization store that maps the entity to the new property and includes metadata that describes the property. The metadata may include the type of the property (e.g., integer or a date), the name of the property (e.g., “phone”), the location within the user interface for a field for the property, and so on. (The metadata for a pick list is similar to that for a property except that the location for a pick list value may be its index within the pick list.) Such application programs may store the data of custom properties within a customization table of the data store for the application program. The customization table for an entity may include a row for each instance of the entity and a column for each added property of that entity. For example, if the entity is a contact for a shoe salesperson, then a contact customization table may include a row for each contact (e.g., John Smith or Tom Brown) and a column for holding the value of the shoe size of the contact.
Because each end user can customize the application program as they like, the data collected by the end users of the same enterprise may vary significantly and be inconsistent. For example, if the enterprise is a department store, then a shoe salesperson may track the shoe size of customers, while a clothing salesperson may track the neck size of customers. Even the same data collected by two different end users may be named differently. For example, one shoe salesperson may have a custom property named “ShoeSize,” and another shoe salesperson may have a custom property named “FootLength.” Because of the inconsistencies in the naming of custom properties, it can be difficult for the salespeople of the department store to share their customizations.